Drop AGENTS.md's migration list - #148

`AGENTS.md` opened its migration list with `There are seven migrations.` and then walked through seven. It was true when #120 wrote it and has been false since #121; there are ten on `main`. A reader following that paragraph as the map it is meant to be gets handed an inventory that is short by three, and nothing in the paragraph says so.

The count goes rather than moving to ten. A sentence naming a number plus a list of that many entries is a closed claim, and the next migration makes it a contradiction — falsified by anyone adding a file, without a line of `AGENTS.md` changing. A list with no count is a map: the next migration leaves a blank in it rather than a lie. The entries themselves were never wrong, and none of them is touched here.

What replaces it says whose job it is to keep the list whole, because nothing said so before and that is the likeliest reason two migrations fell out of it. The three that add neither a table nor a column are `20260822050002_profile_own_reads.sql`, `20260827124213_account_emails.sql` and `20260830092253_apply_profile_children.sql` — the first two are exactly the two that went missing, which is two out of two and so an observation rather than a cause, but it is the axis the sentence names.

The eighth entry is `my_profile()` and `my_credentials()` (#14), the ninth is `account_emails(uuid[])` (#123), the tenth is `apply_profile_children()` (#128). Each is written in the shape the seven above it use: what the migration establishes, and the one decision in it that a later change could undo without noticing. The eighth is somebody else's migration described in somebody else's document, so it is as close to the surrounding register as I could manage and should be rewritten freely.

The prose below the list gains one clause. It already named `my_profile()` and `my_credentials()` as how the editor reads, and stopped at "saves them with a Server Action" — which reads as though the writes go straight out of the Server Action, and that is the shape #128 replaced. It now says the child tables are written through `apply_profile_children()` in one transaction.

The paragraph is not restructured, and it grows from 462 words on one line to 924. Turning it into a list would make every future entry a one-line diff and would make this diff unreadable, so it is a separate question and not a contributor's to answer.

Nothing in the repository lints or tests Markdown, and `ci.yml` detects a documentation-only branch and skips the build, so there is no run to point at here.

The review on #148 asked whether the list should come out instead, and
reading the ten entries against the migrations they describe says yes.
Each one is a compression of the header of its own migration, including
the first, whose note that the role and the hook are what everything
later refers to reads as though it could only be said from outside the
file: `admin_role_and_access_token_hook.sql` says it in its own second
sentence.

Nothing replaces it. `:403` already opens `Where the schema is decided,
and in what order to read it`, and what it lists is `CONTEXT.md`, the
ADRs and the spec rather than `supabase/migrations/`, which reads as
deliberate: the schema is decided in the spec and applied in the
migrations, and the list was inventorying the application. `:306`
already says where the files are.

Nothing moves either. The third entry's note about the seed was the one
candidate, and `:306` describes `seed/`, `:462` records that the
catalogue reaching production is a decision (#95) rather than a side
effect of a deploy, and the catalogues migration sends a reader of the
empty table to the same issue.

The clause on `:349` from the commit below this one stays. A save's
whole effect on the two child tables travelling through
`apply_profile_children()` in one transaction is not a schema
inventory, and the sentence it joins was stopping at the Server Action.